Software development is an ongoing process whereby a software product initially released to the public can be continually updated through revisions from a software developer/vendor. Software revisions are typically disbursed from a software vendor in what are called “service packs” that can be downloaded or ordered from a vendor for installation on a user's computer. Service packs typically contain program fixes (e.g., for an operating system, application program, etc.) that repair problems (i.e., “bugs”) discovered in the program code after the initial release of the product or after the last service pack release.
In addition to containing fixes for program bugs, service packs can also contain security patches developed specifically to repair vulnerabilities found in program files. Program vulnerabilities discovered after a software product is released can pose significant security threat of attack from hackers and viruses on a world-wide basis. Therefore, once a vulnerability is discovered, the prompt and wide-spread distribution and installation of security patches to computers having vulnerable software is of paramount importance. Theoretically, the use of service packs to achieve such prompt and wide-spread distribution of security patches could be effective. For example, when a software vendor discovers a vulnerability and then develops a security patch, the patch can be posted in the latest service pack on a vendor Web site for users to immediately download and install. This could thwart most hackers and viruses that are intent on exploiting the discovered vulnerability. However, system administrators and other software product users currently face several drawbacks and/or difficulties related to accessing and installing security patches. These difficulties typically result in a significantly lower distribution of such patches than is intended by the vendor who develops the patch. The result is that vulnerabilities on many computers world-wide are left un-patched, exposing such computers to significant risk.
One difficulty with accessing and installing security patches is that current methods for detecting whether a computer is running software with a known vulnerability require the active use and involvement of the computer. For example, currently available methods can determine whether particular versions of software products on a computer are in need of being updated (e.g, with a security patch). However, only those software products actively running on the computer are included in this determination. Secondary operating systems and applications that are not actively running on a computer are not considered, and therefore may have a security vulnerability that goes un-noticed and un-fixed. For those products actively running on a computer, a user can review a list of available updates and select updates for installation. Some updates may be critical updates designed to protect a computer from known security vulnerabilities. Various updates require a user to restart the computer before the installation is complete. In addition, a user must actively select the updates and install them. For these and other reasons, current methods for accessing and installing security patches are less than effective.
Another difficulty in accessing and installing security patches is that of knowing whether or not a security patch is needed on a computer. It is sometimes difficult for users to know if their computers are running software that is vulnerable. Furthermore, current methods for detecting whether a computer is running software with a known vulnerability may not be able to detect certain configurations of a software product known to be vulnerable. For example, shared versions of some software products can be distributed as part of other products. Thus, although a shared version of a product may contain the same vulnerability as the full version of the product, the shared version may not be recognized as a product that needs a security patch update. Thus, shared versions of software products that are known to have security vulnerabilities often go un-fixed.
Other problems with accessing and installing security patches relate to the conventional “service pack” method by which such patches are delivered. Downloading and installing services packs is a time intensive and manual process that many system administrators simply do not have time to perform. Therefore, even when administrators intend to install security patches, the time between the release of a security patch and its installation on a given system can be weeks, months, or years. Thus, the risk of attack through a security vulnerability may not be alleviated in such systems until long after the software vendor has issued a security patch.
Furthermore, system administrators often choose not to download and install service packs containing security patches, even though they understand the relevant security risks. The reason for this is that the installation of a service pack itself brings the risk of system regressions that can introduce unwanted changes in system behavior. Administrators often devote significant time and effort toward debugging a system so that it functions as desired. As mentioned above, however, service packs represent an evolution of a previous version of a software product that includes the most recent updates to a product's code base (i.e., the scope of changes is not restricted to security patches only). In addition to introducing new and intended behaviors into a system, recent code updates in a service pack may introduce unknown bugs into a system that can cause the system to behave unexpectedly, which, in turn, can create significant problems for a system administrator. Thus, systems frequently are not updated with important security patches intended to fix vulnerable program files, because administrators do not want to risk regressions.
Accordingly, a need exists for a way to implement patching of security vulnerabilities in program file in an automatic, comprehensive, reliable and regression-free manner.